Software providers may use schemas to organize data. A schema is an organization of data in a hierarchy which may represent relationships between the data. Software providers may deliver software systems with schemas to their customers. The customers may need to customize the schemas to accommodate their particular needs. The software providers may continue to develop the software and update the schemas to implement improvements to the software systems. The improvements may be for many customers and may not include the customizations needed for a particular customer's needs. A problem occurs when the software provider delivers an updated software system with an updated schema to the customer with a customized schema. The software provider needs to merge the customized schema with the updated schema. However, merging the customized schema with the updated schema may be difficult because the changes to the schema to generate the customized schema and the updated schema may be inconsistent and/or because it may be prohibitively expensive to have a computer professional merge the changes manually. Manually merging the changes may be particularly expensive when the software is updated frequently and/or when highly skilled professionals are required to perform the merging.
FIG. 1A illustrates an original schema 100 which organizes different types of payment categories 102 for a hospital. A computer system (not illustrated) may use the original schema 100 to calculate a payment category 102 for a patient. The original schema 100 may be a hierarchy of categories 102 linked together with links 106. A category 102 may include additional information 104 such as forms 104.1, 104.2. In original schema 100 there are four payment categories 102.1: citizen 102.2, citizen unemployed 102.4, citizen employed 102.6, and non-citizen 102.3. The payment category 102.1 may determine a discount for billing a patient, e.g. if the patient is a non-citizen 102.3 the patient may receive no discount and have to pay 100% of the bill. The computer system may start at payment category 102.1. The computer system may then retrieve the two categories citizen 102.2, and non-citizen 102.3. The computer system may then prompt an administrative person as to whether the patient is a citizen or non-citizen. The administrative person may enter that the patient is a citizen. The computer system may then retrieve the categories citizen self-employed 102.4 and citizen employed 102.6, under citizen 102.2. The computer system may then prompt the administrative person as to whether the patient is unemployed or employed by a company. The administrative person may enter that the patient is unemployed. The computer system may then retrieve a discount percentage associated with the category citizen unemployed 102.4. For example, the patient may have to pay only 70% of the billing if the patient is a citizen and unemployed, and only 90% of the billing if the patient is a citizen and employed, but 100% of the billing if the patient is a non-citizen. The category citizen unemployed 102.4 and category citizen employed 102.6 may include respectively Form A 104.1 and Form B 104.2, which may be forms to be filled to verify that the patient is entitled to the discount received for the respective category.
FIG. 1B illustrates changes to the schema of FIG. 1A to generate a second schema 120 (hereinafter referred to as “customized schema”). The software provider may have delivered to a customer the original schema 100 of FIG. 1A. The customer may have needed to customize the original schema 100 to accommodate particular needs of the customer. For example, continuing with the example of FIG. 1A, if a particular hospital had a rule that if you were wealthy then you would receive no discount on the billing, then the original schema 100 would need to be changed to reflect this rule. In FIG. 1B, customized schema 120 is a customized version of original schema 100 with category citizen wealthy 102.7 being added. Now, when the computer system determines that the patient is a citizen 102.2, the computer system may then query an administrator as to whether or not the patient is wealthy. If the patient is wealthy, the patient may have to pay 100% of the billing. Additionally, Form A 104.1 and Form B 104.2 may have been customized to Form A″ 104.3 and Form B′ 104.4 to include proof that the patient is not wealthy to receive the discounted billing.
FIG. 1C illustrates changes to the original schema 100 of FIG. 1A to generate a first schema 140 (hereinafter referred to as “updated schema”). The software provider may have updated the original schema 100 to accommodate the needs of many hospitals. The changes to the original schema 100 include adding categories 102 for dependent children 102.7, 102.9, and for no children 102.8, 102.10. A hospital may now use the updated schema 140 to charge patients with dependent children 102.7, 102.9 a greater discount than patients with no children 102.8, 102.10. The updated schema 140 may include additional forms 104.
A problem occurs when updated schema 120 and customized schema 140 need to be merged to update the software system of the hospital that is using the customized second schema 120. It may be difficult to determine whether or not the two schemas 120, 140 may be merged and if they can be merged how to merge the two schemas 120, 140. Additionally, it may be labor intensive and prone to error for a skilled professional to merge the two schemas 120, 140 manually.
Therefore, there is a need in the art for methods and apparatuses to merge a customized schema and an updated schema. The customized schema and the updated schema both being changes to the same schema.